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Research  Topic  Description 


TARDEC's  mission  is  to  conduct  full  service  life  cycle  engineering  support  to  the  TACOM  Life 
Cycle  Management  Command  and  the  Program  Executive  Offices  associated  with  it,  for  all  DoD 
ground  vehicle  system  acquisition  and  life  cycle  management.  The  TARDEC  Systems 
Engineering  Group  is  constantly  looking  for  systems  engineering  methods,  tools  and  procedures 
(MPT)  to  support  this  mission.  TARDEC  has  found  that  many  systems  engineers  from  the 
automobile  industry  have  significant  experience  in  systems  engineering  (SE),  but  lack 
experience  in  some  of  the  competencies  deemed  critical  to  systems  engineering  in  the  DoD 
workforce.  This  research  will  identify  the  differences  between  education  needs  of  system 
engineers  in  both  industry  and  the  DoD  workforce,  and  develop  methods,  processes  and  tools 
to  address  the  shortfalls  in  educating  SEs  in  the  DoD  workforce. 
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1  Introduction 


RT26  "Vehicle  Systems  Engineering  and  Integration  Activities"  was  a  SERC  project  sponsored  by 
U.S.  Army  RDECOM/TARDEC  in  the  period  from  9/01/2010  to  6/30/2012.  RT-26  was  sponsored 
by  the  US  Army  RDECOM/TARDEC  to  develop  Systems  Engineering  (SE)  materials  supporting 
the  RDECOM/TARDEC  SE  Group.  The  project  was  executed  with  close  coordination  between 
WSU  and  RDECOM/TARDEC  SE  Group.  During  the  course  of  the  RT26  project,  the 
RDECOM/TARDEC  SE  Group  continued  to  develop  and  refine  their  SE  practices  and  procedures. 
The  specific  focus  and  emphasis  of  the  project  evolved  in  coordination  with  developments  in 
RDECOM/TARDECs  SE  practices  and  procedures. 

RT26  was  executed  by  Wayne  State  University  (WSU)  .  The  project  consisted  of  four  technical 
tasks: 

1.  Analyze  TARDEC  SE  Needs 

2.  Identify  SE  Education  Gaps 

3.  Conduct  Case  Studies  Addressing  the  Needs  and  Gaps 

4.  Disseminate  Results 

Summaries  of  the  results  of  each  of  these  tasks  follow.  The  major  technical  effort  was  devoted 
to  two  case  studies,  described  in  sections  2  and  3.  Detailed  research  products  are  contained  in 
the  accompanying  digital  files,  and  referenced  in  the  text.  The  two  case  studies  were  identified 
through  the  analysis  of  TARDEC  SE  needs  and  identification  of  SE  education  gaps.  The  first  case 
study  was  a  short  (3  month)  effort  to  develop  formalization  for  physical  reserve  capacity 
requirements  for  versatile  ground  vehicles.  The  second  case  study  was  an  extensive  effort 
consisting  of  six  phases  over  15  months,  to  illustrate  the  evolution  of  the  "Project  Plan"  for  SE 
and  project  management,  required  by  RDECOM  OPORD  10-065  issued  in  August  2010,  for 
Science  and  Technology  (S&T)  projects. 


1.1  Task  1:  Analyze  TARDEC  SE  Needs 

RDECOM/TARDEC  is  the  research,  development  and  engineering  command  supporting  the 
AMC/TACOM  life  cycle  management  command  (LCMC).  TARDEC's  SE  group  supports  TACOM 
by  providing  SE  services  and  personnel  for  acquisition  programs.  TARDEC's  SE  group  develops 
SE  policies,  procedures,  methods,  tools  and  training  materials  within  the  context  of  RDECOM  SE 
policy.  TARDEC's  SE  group  performs  SE  for  TARDEC  Science  and  Technology  (S&T)  programs, 
and  trains  TARDEC  personnel  outside  the  SE  group  in  SE  practices. 

From  2002  to  2009  the  Future  Combat  Systems  (FCS)  acquisition  program  had  been  the  Army's 
capstone  ground  combat  vehicle  modernization  program.  TARDEC  S&T  projects  were  justified 
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by  supporting  FCS.  In  2009,  the  DoD  cancelled  the  FCS  program.  Specific  criticisms  were  cost 
growth,  reliance  on  immature  technologies  in  the  expectation  that  they  would  become 
available  in  time  for  integration  and  fielding  with  the  FCS,  and  a  development  timeline  so  long 
that  the  operational  needs  had  changed  so  much  that  the  FCS  system  requirements  became 
irrelevant.  In  cancelling  the  FCS  program,  the  Army  was  directed  to  eliminate  the  use  of 
contractor  Lead  System  Integrators  (LSI),  and  instead  to  perform  the  LSI  function  internally. 

In  lieu  of  the  FCS  program,  the  TACOM  was  directed  to  develop  a  Ground  Combat  Vehicle  (GCV) 
that  would  service  the  full  spectrum  of  Army  operations,  would  have  the  versatility  to 
incorporate  new  capability  packages  in  response  to  threat  developments  and/or  technology 
maturation,  would  be  a  platform  on  which  to  base  for  a  family  of  ground  vehicle  systems,  and 
would  be  fielded  in  seven  years. 

The  Army  issued  the  set  of  requirements  and  Request  for  Proposal  (RFP)  for  the  GCV  in 
November  2010.  The  GCV  is  now  the  Army's  highest-priority  ground  vehicle  modernization 
effort.  The  initial  focus  is  for  an  Infantry  Fighting  Vehicle  capable  of  providing  protected 
mobility  for  a  squad  of  9  soldiers.  The  GCV  concept  is  for  a  highly  versatile  system  that  will  be 
able  to  integrate  new,  as-yet-undefined  capability  packages,  and  can  be  modified  quickly  and 
efficiently  to  create  variant  vehicles  for  different  missions.  Versatility  as  part  of  the  acquisition 
strategy  and  incorporating  versatility  into  the  system  requirement  were  novel  actions. 
Traditionally,  systems  were  developed  to  provide  specific  operational  capabilities. 

The  GCV  acquisition  strategy  created  novel  and  unique  challenges  for  SE  with  requirements 
intended  to  lead  to  a  versatile  and  adaptable  platform.  Working  with  the  TARDEC  SE  group,  we 
identified  that  there  was  a  critical  SE  need  to  develop  approaches  to  formulate  system 
requirements  sufficient  to  ensure  a  versatile  and  adaptable  platform.  The  focus  of  the  case 
study  was  limited  to  requirements  for  reserve  capacity.  Modular  design  also  contributes  to 
versatility.  Methods,  procedures  and  tools  (MPT)  for  design  and  analysis  of  modular 
architectures  is  an  outstanding  need,  but  was  not  included  in  the  case  study  scope. 

The  first  case  study  was  designed  to  address  this  need.  It  consisted  of  an  historical  analysis  of 
the  design  limitations  that  had  to  be  overcome  to  achieve  ground  vehicle  versatility,  and  from 
this  derive  what  and  how  to  require  in  terms  of  system  performance.  The  first  case  study  was 
limited  in  scope,  and  did  not  address  evaluation  of  the  level  of  versatility  needed  or  methods  to 
evaluate  the  versatility  of  a  proposal. 

The  GCV  acquisition  program  was  also  novel  in  that  the  requirements  were  "tiered":  the  first 
tier  requirements  were  non-tradable,  but  the  second  and  third  tier  requirements  were 
tradeable,  i.e.,  the  bidder  could  select  which  to  accept  and  which  to  reject,  to  meet  cost  and 
schedule  objectives.  Development  time,  unit  production  cost,  and  operating  and  sustainment 
costs  had  equal  priority  with  the  first-tier  performance  requirements.  We  identified  a  need  for 
SE  MPT  for  integrated  cost,  schedule  and  performance  risk  identification  and  analysis,  to 
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support  requirements  tradeoffs  in  the  GCV  program.  This  SE  need  was  not  selected  for  a  case 
study. 

In  summary,  we  identified  three  critical  needs  for  SE  MPT,  although  only  one  was  selected  for  a 
case  study.  The  critical  SE  needs  were: 

•  MPT  to  express  requirements  for  infrastructure  reserve  capacity  for  versatile  systems 
(selected) 

•  MPT  to  evaluate  cost/schedule/performance  risk  tradeoffs  in  developing  quantitative 
reserve  capacity  requirements  for  versatile  systems  (not  selected) 

•  MPT  for  the  design  and  analysis  of  modular  architectures  for  complex  systems  with 
subsystem  interactions  on  multiple  dimensions  (not  selected) 


1.2  Task  2:  Identify  SE  Education  Gaps 

In  August,  2010,  RDECOM  issued  OPORD  10-065  "RDECOM  Systems  Engineering  Policy" 
establishing  an  Organizational  Standard  Process  (OSP)  to  apply  rigorous  Systems  Engineering 
and  Project  Management  to  Science  and  Technology  (S&T)  projects,  following  the  intent  of  the 
Weapon  Systems  Acquisition  Reform  Act  (WSARA)  of  2009.  OPORD  10-065  includes  a  template 
and  guidance  for  a  Project  Plan  addressing  Project  Management  (PM),  SE  and  SE  Management 
(SEM).  OPORD  10-065  requires  that  the  Project  Plan  be  used  on  all  Army  Technology  Objective- 
Demonstration  (ATO-D)  projects  beginning  in  or  after  1QFY11  (ATO-D  projects  are  now  called 
Technology  Enabled  Capability  Demonstration  -TECD  -  projects).  The  Project  Plan  is  described 
as  a  living  document  to  be  maintained  and  updated  over  the  course  of  the  project  to  help 
assure  quality  and  completeness  of  PM,  SEM  and  SE  activities.  OPORD  10-065  requires  each 
RDECOM  component  to  have  personnel  who  are  trained  and  accountable  to  plan,  coordinate, 
execute  and  assess  the  activities  defined  in  the  policy. 

TARDEC  initiated  an  effort  to  prepare  to  comply  with  the  OPORD.  The  TARDEC  SE  Group  has 
responsibility  for  developing  methods,  tools  and  procedures  for  applying  the  RDECOM  Project 
Plan  template  to  TARDEC  TECD  programs,  to  provide  tools  for  project  SE,  and  to  provide  trained 
personnel.  TARDEC  began  developing  internal  policies,  procedures,  and  guidelines  to  apply  the 
OPORD,  and  began,  in  1QFY11,  to  apply  the  OPORD  policy  to  new  TECD  projects.  Working  with 
the  TARDEC  SE  group,  we  identified  a  critical  SE  education  gap  being  the  lack  of  a  specific 
example  of  a  Project  Plan  as  it  evolves  over  the  course  of  an  S&T  project  to  use  for  personnel 
training  and  as  an  example  to  follow. 

The  second  case  study  was  designed  to  address  this  gap  by  creating  an  example  of  the  Project 
Plan,  showing  its  evolution  over  the  course  of  a  project.  TARDEC's  policies  and  procedures  to 
comply  with  the  OPORD  were  being  developed  in  parallel  with  the  conduct  of  the  second  case 
study. 
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1.3  Task  3:  Conduct  Case  Studies  Addressing  the  Needs  and  Gaps 


We  conducted  two  case  studies.  The  first  case  study,  conducted  in  a  3-month  period  from 
January  to  March  2011,  reviewed  factors  that  limited  and  contributed  to  the  versatility  and 
adaptability  of  ground  vehicle  systems,  developed  a  taxonomy  of  mechanical  properties  that 
are  needed,  and  developed  a  formalism  to  express  the  requirements  in  a  way  that  avoided 
unintentional  conflicts  with  other  performance  requirements.  The  second  case  study, 
conducted  over  a  15-month  period  from  April  2011  to  June  2012,  illustrated  the  evolution  of 
the  OPORD  10-065  Project  Plan  for  a  S&T  project  by  producing  snapshots  of  the  Project  Plan 
and  accompanying  technical  documentation  at  six  points  in  the  project  life  cycle.  The  second 
case  study  was  organized  into  six  subcases,  one  for  each  of  the  six  major  technical  reviews. 

Ground  Vehicle  Versatility  Systems  Engineering  Case  Study 

Ground  vehicle  versatility  refers  to  the  ability  to  produce  variants  of  a  vehicle  to  support  the  full 
Range  of  Military  Operations  from  major  combat  operations  to  humanitarian  assistance,  across 
the  spectrum  of  terrains  and  environments: 

•  Basing  a  product  line  of  mission-variants  on  a  common  vehicle  platform 

•  Integrating  new  capability  packages  addressing  operational  needs  identified  by 
commanders  in  the  field,  and  to  integrate  new  technologies  as  they  mature. 

Historically,  the  Army  has  produced  versatile  ground  vehicles  by  an  incremental,  hit-or-miss 
evolutionary  process  in  which  vehicles  are  modified  to  overcome  limiting  physical 
characteristics.  Some  vehicle  designs  turn  out  to  be  more  conducive  to  expansion  than  others. 

The  objective  of  the  case  study  was  to  develop  guidelines  and  templates  to  define 
requirements  that  will  lead  to  versatile  ground  vehicles  at  the  initial  design,  bypassing  the 
costly  and  time  consuming  process  of  incremental  evolution.  The  resulting  MPT  had  three 
components: 

1.  Identification  of  the  critical  physical  system  dimensions/parameters  on  which  to  require 
reserve  capacity 

2.  Guidelines  and  methodology  to  analyze  the  physical  architecture  to  identify  subsystems 
for  which  to  require  reserve  capacity 

3.  A  grammar  to  express  the  requirements  for  reserve  capacity,  including  derived 
interaction  and  compatibility  requirements 

The  scope  of  this  study  was  limited  to  defining  requirements  for  physical  characteristics  that 
can  limit  or  enable  versatility.  It  did  not  include  MPT  to  evaluate  the  tradeoffs  among  the  level 
of  reserve  capacity,  potential  needs/risks,  cost/schedule/performance  tradeoffs.  It  did  not 
include  modular  design  and  its  role  in  system  versatility.  DoD  acquisition  regulation  5000.2 
requires  consideration  of  modular  and  open  system  architecture  in  system  design.  Existing 
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guidelines  and  evaluation  methods  for  modular  design  that  are  largely  procedural  and 
subjective  (see  Program  Managers  Guide:  A  Modular  Open  Systems  Approach  to  Acquisition 
Version  2,  Open  Systems  Joint  Task  Force,  http://www.acq.osd.mil/osjtf/pmguide.html,  2004). 
Systems  engineering  research  is  needed  to  develop  analytical  and  objective  MPT  tradeoffs 
between  integral  and  modular  design,  modularity  metrics,  and  MPT  for  modular  physical  and 
functional  architectures  are  needed,  but  are  outside  the  scope  of  this  study. 

The  first  case  study  is  documented  in  section  2.  The  report  on  the  case  study  is  organized  into 
four  technical  sections.  Section  2.2  reviews  the  strategic  motivation  for  versatile  ground 
vehicles  and  DoD  systems.  Section  2.3  describes  the  systems  engineering  research  approach. 
Section  2.4  presents  the  case  studies  and  lessons  for  versatile  design.  Section  2.5  presents  the 
findings  and  recommendations. 

RDECOM  OPORD 10-065  Project  Plan  Case  Study 

The  Project  Plan  Case  Study  used  as  a  concrete  example  a  specific  TARDEC  S&T  project  that  was 
nearing  completion.  The  project  preceded  the  OPORD  10-065  requirement,  so  no  Project  Plan 
had  been  prepared,  but  the  project  was  current  and  the  information  was  available  with  which 
to  reconstruct  what  the  Project  Plan  evolution  would  have  been.  The  specific  project  was  to 
develop  a  compact  mast  system  to  elevate  antennas  and  a  sensor  pod  for  the  Man- 
Transportable  Robotic  System  (MTRS)  PoR.  The  acquisition  agent  for  the  MTRS  PoR  is  the 
Robotic  System  Joint  Program  Office  (RS-JPO),  under  the  TACOM  Program  Executive  Office  for 
Combat  Support  and  Combat  Service  Support  (PEO  CS-CSS). 

The  case  study  produced  snapshots  of  the  Project  Plan  and  accompanying  technical  annexes  for 
each  of  the  six  major  technical  reviews: 

1.  Stakeholder  Needs  Review  (SNR) 

2.  System  Requirements  Review  (SRR) 

3.  System  Functional  Review  (SFR) 

4.  Preliminary  Design  Review  (PDR) 

5.  Critical  Design  Review  (CDR) 

6.  Test  Readiness  Review  (TRR) 

The  Project  Plan  template  in  OPORD  10-065  has  26  sections.  Our  case  study  included  nine 
additional  technical  annexes  with  additional  PM,  SEM  and  SE  content  amplifying  and  detailing 
sections  of  the  Project  Plan 

The  scope  of  case  study  was  to  create  a  complete  example  application  of  the  Project  Plan  policy 
over  the  life  of  an  S&T  project.  We  were  not  tasked  to  critique  or  make  recommendations  for 
the  Project  Plan  template  and  guidance.  In  order  to  provide  the  most  useful  product  for  the 
TARDEC  sponsor,  we  coordinated  closely  with  the  TARDEC  SE  group  to  ensure  that  our  example 
would  correspond  to  TARDEC's  evolving  policies,  guidance  and  templates  for  implementing 
OPORD  10-065.  The  detailed  reviews  and  feedback  on  the  Project  Plan  iterations  were 
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invaluable  for  completing  the  case  study  and  ensuring  consistency  with  TARDEC  SE  policies  and 
practices. 

The  second  case  study  is  described  in  section  3.  Specific  research  products  are  contained  in  the 
accompanying  files,  and  referenced  in  the  text. 


1.4  Task  4:  Disseminate  Results 

The  results  of  the  first  case  study  were  presented  to  the  SE  community  at  the  third  SERC  annual 
review.  Further  coordination  of  the  first  case  study  with  RDECOM/TARDEC  will  take  place  at 
TARDEC's  scheduling  and  request. 

The  snapshots  of  the  Project  Plan  and  technical  annexes  were  provided  to  RDECOM/TARDEC  for 
use  as  examples  to  help  guide  SE  personnel  in  applying  RDECOM  OPORD  10-065  and  associated 
TARDEC  guidance.  OPORD  10-065  specifies  that  each  organizational  Chief  SE  and  project  SE 
Leads  will  take  the  SE  Advanced  course  (as  well  as  the  Technology  Planning  Continuous 
Learning  Module  offered  by  the  Defense  Acquisition  University  and  be  Systems  Planning, 
Research  Development  and  Engineering  -  Program  Systems  Engineer  Level  III  certified).  As  of 
completion  of  RT-26  the  SE  Advanced  course  is  still  under  development.  The  second  case  study 
artifacts  -  snapshots  of  the  Project  Plan  and  technical  annexes  -  can  potentially  be  used  as  part 
of  the  course  material,  however  development  of  curriculum  is  outside  the  scope  of  the  Systems 
Engineering  Research  Center  (SERC)  contract  scope. 

2  Case  Study  1:  Requirements  Definition  For  Versatile  Ground  Vehicles 


2.1  Introduction 

Versatility  in  defense  systems  has  become  a  strategic  priority.  Recent  conflicts  highlight  the 
need  for  DoD  to  be  able  to  field  capabilities  and  systems  responding  rapidly  to  changing 
threats.  The  traditional  material  acquisition  practice  of  defining  specific  point  requirements  for 
specific  threats  years  before  the  system's  initial  use  is  unable  to  keep  up  with  the  pace  of 
events  and  agility  of  adversaries.  Systems  of  the  future  need  to  be  flexible  and  adaptable  to 
changing  environments.  Ground  vehicle  versatility  is  a  central  goal  of  Army  Modernization. 
The  primary  benefit  of  ground  vehicle  versatility  is  the  ability  to  rapidly  field  capabilities 
addressing  operational  needs  identified  by  commanders  in  the  field.  Additional  benefits 
include  reduced  logistics  burden  from  common  maintenance,  equipment,  and  spares,  reduced 
acquisition  costs  by  retrofitting  rather  than  new  starts,  lengthened  inventory  life,  improved 
interoperability,  reliability  and  maintainability. 
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Army  material  acquisition  has  successfully  procured  versatile  ground  vehicles.  The  M113,  the 
Stryker,  the  HMMWV  are  good  examples  of  vehicle  product  lines  with  many  different  mission- 
variants,  and  which  have  been  quickly  retrofitted  to  incorporate  new  or  improved  mission 
equipment.  However  these  vehicles  did  not  initially  have  this  versatility,  nor  were  they  initially 
designed  to  meet  versatility  objectives.  Instead,  the  vehicles  evolved  over  time.  When  the 
vehicle  was  unable  to  accommodate  a  new  mission  configuration  or  equipment,  the  base 
design  was  changed  to  provide  increased  capacity.  This  eventually  led  to  versatile  platforms. 
Some  basic  designs  were  more  conducive  to  being  modified  and  expanded  than  others,  leading 
to  larger  and  more  successful  product  lines. 

The  objective  of  this  systems  engineering  initiative  is  to  research  methods,  procedures  and 
tools  (MPT)  to  define  ground  vehicle  requirements  that  will  lead  to  versatile  platforms,  thereby 
avoiding  the  lengthy,  inconsistent,  hit-or-miss  evolutionary  processes.  Historically,  versatility 
has  been  achieved  by  trial-and-error  discovery  and  correction  of  limiting  factors.  The  goal  of  a 
systems  engineering  approach  to  requirements  definition  for  versatile  platforms  is  to  design 
versatility  in  from  the  start,  avoiding  the  lengthy  and  costly  field-and-fix  historical  pattern. 

Versatility  is  one  of  the  core  non-tradable  requirements  of  the  current  Ground  Combat  Vehicle 
(GCV)  program.  The  GCV  performance  specifications  included  requirements  intended  to 
provide  the  capacity  for  growth,  flexibility  and  expansion.  The  objective  of  this  effort  is  to 
provide  a  more  complete  and  rigorous  framework  to  define  requirements  for  physical 
characteristics  leading  to  versatility  ground  vehicle  platforms.  This  research  expands  and 
refines  the  GCV  approach  to  address  other  physical  characteristics  that  limited  the  capacity  for 
growth  and  expansion  in  the  historical  evolution  of  versatile  ground  vehicle  platforms. 

Two  factors  contribute  to  platform  versatility:  reserve  capacity  and  modular  design.  This  study 
is  limited  to  requirements  definition  for  reserve  capacity  in  the  physical  characteristics  of  the 
design.  The  focus  of  this  case  study  is  to  identify  the  dimensions  on  which  to  require  reserve 
capacity  and  a  formalism  to  express  the  requirement.  MPT  to  recommend  the  level  of  reserve 
capacity  or  to  evaluate  cost/performance  risks  and  tradeoffs  are  outside  the  scope  of  this  initial 
case  study.  MPT  to  address  tradeoffs  between  modular  and  integral  design,  metrics  for 
modularity,  and  guidelines  for  modular  design  are  outside  the  scope  of  this  study. 

The  findings  and  recommendations  include  MPT  to  define  the  vehicle's  physical  architecture,  a 
list  of  the  critical  physical  characteristics  than  can  limit  or  enable  versatility,  and  generic, 
parametric  statements  of  requirements  for  reserve  capacity  and  subsystem  compatibility.  The 
MPT  are  independent  of  vehicle  physical  configuration,  functions,  and  functional  architecture. 
The  formal  results  are  illustrated  with  specific  examples  of  the  generic  parametric 
requirements. 

Ground  vehicle  versatility  refers  to  the  ability  to  produce  variants  of  a  vehicle  to  support  the  full 
Range  of  Military  Operations  from  major  combat  operations  to  humanitarian  assistance,  across 
the  spectrum  of  terrains  and  environments: 
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•  Basing  a  product  line  of  mission-variants  on  a  common  vehicle  platform 

•  Integrating  new  capability  packages  addressing  operational  needs  identified  by 
commanders  in  the  field,  and  to  integrate  new  technologies  as  they  mature. 

Historically,  the  Army  has  produced  versatile  ground  vehicles  by  an  incremental,  hit-or-miss 
evolutionary  process  in  which  vehicles  are  modified  to  overcome  limiting  physical 
characteristics.  Some  vehicle  designs  turn  out  to  be  more  conducive  to  expansion  than  others. 

The  objective  of  this  study  is  to  develop  guidelines  and  templates  to  define  requirements  that 
will  lead  to  versatile  ground  vehicles  at  the  initial  design,  bypassing  the  time  consuming  process 
of  incremental  evolution. 

The  scope  of  this  study  is  limited  to  defining  requirements  for  physical  characteristics  that  can 
limit  or  enable  versatility.  Modular  design  and  its  role  in  system  versatility  are  not  addressed  in 
this  study.  DoD  acquisition  regulation  5000.2  requires  consideration  of  modular  and  open 
system  architecture  in  system  design.  Existing  guidelines  and  evaluation  methods  for  modular 
design  that  are  largely  procedural  and  subjective  (see  Program  Managers  Guide:  A  Modular 
Open  Systems  Approach  to  Acquisition  Version  2,  Open  Systems  Joint  Task  Force, 
http://www.acq.osd.mil/osjtf/pmguide.html,  2004).  Systems  engineering  research  is  needed  to 
develop  analytical  and  objective  MPT  tradeoffs  between  integral  and  modular  design, 
modularity  metrics,  and  MPT  for  modular  physical  and  functional  architectures  are  needed,  but 
are  outside  the  scope  of  this  study. 

The  documentation  is  organized  into  four  sections.  Section  2.2  reviews  the  strategic  motivation 
for  versatile  ground  vehicles  and  DoD  systems.  Section  2.3  describes  the  systems  engineering 
research  approach.  Section  2.4  presents  the  case  studies  and  lessons  for  versatile  design. 
Section  2.5  presents  the  findings  and  recommendations. 


2.2  Motivation 

Versatile  systems  are  systems  that  can  be  quickly  and  efficiently  adapted  for  different 
configurations  and  mission  payloads.  Benefits  of  versatile  systems  include 

•  Reduced  time  and  cost  to  upgrade  the  system 

•  Reduced  manufacturing  change-over  time  and  cost 

•  Reduced  fielding  time  and  cost 

•  Reduced  logistics  burden  over  the  family  of  systems  based  on  a  common  platform 

•  Faster  and  less  costly  response  to  adapt  to  changes  in 

•  Threats 

•  Operational  situations  and  needs 

•  DoD  budget,  force  structure  and  system  mix 

•  Technology  capability  developments  and  burdens 
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System  versatility  is  a  strategic  objective  of  the  Office  of  the  Secretary  of  Defense  for  Research 
and  Engineering:  "The  Office  of  the  Deputy  Assistant  Secretary  of  Defense  for  Systems 
Engineering  (ODASD(SE))  is  leading  the  "System  2020"  strategic  initiative  on  behalf  of  the  Office 
of  the  Assistant  Secretary  of  Defense  for  Research  and  Engineering.  Its  objective  is  to 
fundamentally  change  the  capabilities  for  the  design,  adaptation,  and  manufacture  of  defense 
systems.  Recent  conflicts  have  highlighted  the  need  for  DoD  to  be  able  to  field  capabilities  and 
systems  to  respond  rapidly  to  changing  threats.  The  Department  is  exploring  various 
approaches  as  alternatives  to  the  typical  practice  of  fielding  systems  that  respond  to  specific 
point  requirements  that  were  defined  years  before  the  system's  initial  use.  Current 
requirements-based  systems  tend  to  lead  to  "point  solutions"  designed  to  address  specific 
threats,  which  in  turn  are  assumed  to  evolve  slowly  in  time.  With  the  pace  of  events  and  agility 
of  adversaries,  systems  of  the  future  need  to  be  far  more  flexible,  adaptable  to  changing 
environments."  (http://www.acq.osd.mil/se/initiatives/init_s2020.html). 

The  Army's  vision  for  Force  Modernization  and  force  generation  (AFOREN)  emphasizes  vehicle 
versatility  as  a  way  to  response  rapidly  to  changes  in  the  operational  environment  and 
operational  needs  identified  by  commanders  in  the  field.  This  vision  and  the  central  role  of 
versatility  were  articulated  in  a  presentation  made  in  2009  by  LTG  Vane  (then  Director  of  the 
Army  Capabilities  Integration  Center  and  Deputy  Commanding  General,  Futures)  articulating 
the  need  for  vehicle  versatility  to  incorporate  capability  packages  addressing  needs  identified 
by  commanders  in  the  field  and  to  exploit  technology  spin-out. 

The  need  for  versatility  is  especially  pronounced  with  respect  to  flexible  armor  solutions  that 
can  be  tailored  for  the  operational  conditions.  The  Army's  2010  wheeled  vehicle  acquisition 
strategy  observed  that:  "Without  a  front  line,  all  vehicles  proved  to  be  targets  of  enemy  fire, 
particularly  emergent  threats  of  improvised  explosive  devices  that  would  drive  the  need  for 
greater  and  greater  protection  levels  across  the  truck  fleet.  The  result  was  a  fleet  designed 
without  the  burden  of  armor  protection  and  the  corresponding  automotive  impacts  that 
potential  add-on  armor  would  have  on  critical  truck  sub-components  like  the  engine, 
suspension,  transmission,  and  axles."  The  Long  Term  Armor  Strategy  response  is  to  design  and 
build  tactical  trucks  with  an  A-kit,  B-kit  modular  armor  approach,  allowing  trucks  to  adjust  their 
protection  to  the  potential  threats  they  will  face  in  combat.  The  A-kit  is  designed  to  accept 
additional  armor  in  the  form  of  a  B-kit.  The  A-kit/B-kit  concept  allows  the  Army  flexibility  in 
several  areas:  the  armor  B-kit  can  be  taken  off  when  not  needed  --  reducing  unnecessary  wear 
and  tear  on  the  vehicles;  the  Army  can  continue  to  pursue  upgrades  in  armor  protection  -- 
adapting  B-kits  to  match  the  threat;  and  the  versatility  of  the  B-kit  enables  the  transfer  of 
armor  from  unit  to  unit  making  armor  requirements  affordable  by  pooling  assets  versus  buying 
armor  that  is  only  for  one  vehicle. 
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2.3  Objectives,  Scope  and  Approach 

The  objective  of  this  study  is  to  produce  methods,  procedures  and  tools  (MPT)  to  define  ground 
vehicle  requirements  that  will  lead  to  versatile  platforms,  thereby  avoiding  the  lengthy, 
inconsistent,  hit-or-miss  evolutionary  processes.  The  goal  is  to  provide  a  rigorous  framework  to 
define  requirements  for  reserve  capacity  physical  characteristics  enabling  platform  versatility. 

The  specific  objectives  are  to  develop 

1.  a  list  of  the  critical  physical  characteristics  than  can  limit  or  enable  versatility, 

2.  MPT  to  define  the  vehicle's  physical  architecture  for  physical  characterization,  and 

3.  generic,  parametric  statements  of  requirements  for  reserve  capacity  and  subsystem 
compatibility. 

The  MPT  are  independent  of  vehicle  physical  configuration,  functions,  and  functional 
architecture.  The  formal  results  are  illustrated  with  specific  examples  of  the  generic  parametric 
requirements. 

The  research  approach  combines  two  elements.  It  builds  on  the  approach  to  defining  reserve 
capacity  requirements  taken  in  the  GCV  program.  Versatility  is  one  of  the  core  non-tradable 
requirements  of  the  GCV  program,  and  the  GCV  performance  specifications  included  some 
requirements  intended  to  provide  reserve  capacity  for  growth,  flexibility  and  expansion.  It 
expands  and  refines  the  GCV  approach  to  address  other  physical  characteristics  that  limited  the 
capacity  for  growth  and  expansion  in  evolution  of  historical  versatile  ground  vehicle  platforms. 
These  case  studies  include  the  HMMWV,  M113,  Stryker,  and  several  foreign  tactical  vehicles. 

Two  factors  contribute  to  platform  versatility:  reserve  capacity  and  modular  design.  The  scope 
of  this  study  is  limited  to  requirements  definition  for  reserve  capacity  in  the  physical 
characteristics  of  the  design.  MPT  to  address  tradeoffs  between  modular  and  integral  design, 
metrics  for  modularity,  and  guidelines  for  modular  design  are  outside  the  scope  of  this  study. 


2.4  Cases  and  Lessons 


2.4.1  GCV 


The  GCV  is  envisioned  to  be  a  class  of  vehicles  that  includes  a  range  of  specific  platform 
capabilities  by  variant  roles  including  an  Infantry  Fighting  Vehicle  (IFV),  Reconnaissance, 
Command  and  Control,  and  General  Support  (e.g.,  Ambulance/Medical  Evacuation, 
Engineering,  Security/Convoy  escort,  and  Armored  Security).  The  GCV  design  is  intended  to 

Contract  Number:  H98230-08-D-01 71  D02,  TT02,  RT0026 

Report  No.  SERC-2012-TR-015-5 
August  31, 2012 

UNCLASSIFIED 

16 


facilitate  integration  of  new  capability  packages  addressing  operational  needs  identified  by 
commanders  in  the  field,  and  new  technologies  as  they  mature,  replacing  or  complementing 
existing  functional  elements. 

The  GCV  IFV  Performance  Specification  contains  a  section  on  requirements  for  growth, 
expansion  and  flexibility.  The  requirements  for  excess  capacity  to  handle  increased  mass 
addressed  individual  elements  of  the  vehicle,  not  the  vehicle  system,  e.g. 

•  The  prime  structures  shall  be  designed  for  an  X%  weight  growth 

•  The  turret  kinematic  components  shall  be  designed  to  meet  all  performance 
requirements  with  an  X%  weight  growth 

•  The  running  gear  shall  be  designed  to  meet  all  performance  requirements  with  an  X% 
weight  growth 

•  The  engine  shall  be  designed  to  meet  all  performance  requirements  with  an  X%  weight 
growth 

•  The  thermal  management  shall  be  designed  to  meet  all  performance  requirements  with 
an  X%  waste  heat  rejection  capacity. 

These  requirements  statements  assumed  a  functional  architecture  (prime  structure,  turret, 
running  gear,  etc.).  Other  sections  of  the  Performance  Specification  used  more  general  and 
concise  statements  of  the  form:  The  GCV  shall  perform  its  mission,  meeting  all  performance 
requirements,  under  conditions  XYZ.  Ideally,  the  requirements  definition  can  be  expressed  in  a 
general  way  that  is  not  tied  to  a  specific  functional  architecture. 

The  Performance  Specification  also  included  requirements  for  reserve  data  processing  capacity 
expressed  in  terms  of  data  bus  bandwidth,  processor  throughput,  computer  memory, 
additional  card  slots  and  I/O  ports.  Ideally,  the  requirements  definition  can  be  expressed  in  a 
general  way  that  is  not  tied  to  a  specific  computer  and  data  processing  hardware  approaches. 

The  GCV  requirements  addressed  reserve  card  slots  and  I/O  ports  in  each  hardware  item  with  a 
backplane  architecture,  but  did  not  otherwise  include  requirements  for  reserve  volume  and 
surface  area  to  mount  additional  components. 

Lessons,  insights,  &  observations:  Versatility  requirements  include  reserve  capacity  to 
accommodate  increase  in  mass.  The  requirements  should  ensure  that  all  subsystems  whose 
performance  is  affected  are  able  to  accommodate  the  increased  mass.  The  requirements  should 
be  expressed  in  terms  of  accomplishing  functions  to  target  levels,  rather  than  the  capacity  of 
subsystems  so  that  the  requirements  can  be  expressed  independently  of  the  allocated  baseline 
(i.e.,  the  allocation  of  physical  subsystems  to  functions). 

Vehicle  Dynamics  Data  Sheets  and  Test  Operating  Procedures  distributed  with  the  GCV 
solicitation  provide  insight  into  additional  physical  characteristics  that  limit  versatility.  The 
Vehicle  Dynamics  Data  Sheets  contained  the  instruction  "If  the  chassis  has  a  turret  and  weapon 
system  attached,  and  if  these  components  will  be  moved  to  various  fixed  positions  or 
continuously  by  a  control  system,  then  must  be  treated  as  individual  rigid/flexible  bodies  with 
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the  same  data  requirements  as  the  hull.  Hull,  turret,  and  weapon  system  should  be 
parameterized  as  loaded  for  nominal  operations  with  equipment,  personnel,  supplies, 
ammunition,  etc.  accounted  for  in  the  mass,  CG  and  inertia  data.  The  spatial  location  of  the  CG 
of  the  sprung  hull,  turret,  elevating  but  not  recoiling  weapon  body,  and  recoiling  weapon  body 
should  be  given  with  respect  to  a  well  defined  point  on  each  body.  The  mass  and  inertia  matrix 
in  a  well  defined  coordinate  system  should  be  provided.  Interconnectivity  of  adjacent  bodies 
must  be  described.  The  axis  of  rotation  between  elevating  and  non-recoiling  mass  and  the 
turret  must  be  located.  The  locations  of  the  hull  of  attachment  points  for  roadarms  and/or 
axels  should  be  indicated." 

The  vehicle  dynamics  data  sheets  addressed  physical  properties  were  addressed  in  the  data 
sheets  that  affect  versatility,  beyond  those  addressed  in  the  Performance  Specification.  These 
factors  directly  affect  vehicle  mobility.  Modifications  to  the  vehicle  will  affect  theses 
characteristics,  and  could  reduce  mobility  unless  the  vehicle  was  required  to  meet  all  the 
mobility  requirements  despite  some  amount  of  change  in  these  physical  characteristics.  These 
characteristics  include: 

•  Mass 

•  Center  of  Gravity  (CG)  location 

•  Moment  of  inertia  matrix 

•  Imbalance  (distances  between  the  GC  location  and  the  axes  of  rotation). 

The  vehicle  dynamics  data  sheets  also  highlighted  that  these  physical  characteristics  apply  not 
just  to  the  vehicle  as  a  whole,  but  to  each  component  that  could  be  moved  to  alternate  fixed 
positions  or  moved  continuously. 

Lessons,  insights,  &  observations:  Mass,  CG  location,  angular  moments,  and  imbalances  are 
critical  physical  characteristics  that  can  limit  versatility.  These  characteristics  apply  to  the 
overall  vehicle  and  each  component  that  rotates  or  can  be  set  to  different  positions. 

Test  Operating  Procedure  "Physical  Characteristics"  TOP  1-2-504,  1972,  U.S.  Army  Test  and 
Evaluation  Command,  requires  reporting  dimensions,  areas,  volumes  and  carrying  capacity  by 
vehicle  compartment. 

Lessons,  insights,  &  observations:  Vehicle  compartment  volumes  are  critical  physical 
characteristics  that  can  limit  versatility. 

GCV  solicitation  included  requirements  for  top-deck  deconfliction:  "The  offeror's  CAD  Model  as 
well  as  the  narrative  and  intervisibility/interference  plots  submitted  in  response  to  L. 4. 1.1. 3  and 
L.4. 1.1.4,  respectively,  will  be  evaluated  to  assess  the  risks  that  the  placement  of  weapons, 
sensors,  communications  and  survivability  subsystems  meet  the  rooftop  deconfliction 
requirements  for  Fields  of  View/Fields  of  Regard,  elevation/depression  angles,  and  ground 
intercepts  as  defined  in  Attachment  025."  The  requirement  shows  that  surface  space  to  mount 
components  and  for  subsystem  work  envelope  is  a  critical,  potentially  limiting  resource. 
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Lessons,  insights,  &  observations:  Surface  areas  to  mount  components  (with  adequate  work 
envelope  without  conflict)  are  a  critical  physical  characteristic  that  can  limit  versatility. 


2.4.2  HMMWV 


HMMWV  Evolution 

AM  General  produces  15  different  HMMWV  variants  with  44  interchangeable  parts  that  are 
used  in  more  than  one  position  (see  figure  1).  The  HMMWV  is  constructed  on  a  steel  frame 
with  boxed  frame  rails  and  five  cross  members  constructed  from  high-grade  alloy  steel.  The 
aluminum  body  panels  are  riveted  and  bonded  together  with  adhesives  to  provide  additional 
strength.  The  body  is  designed  to  flex  to  accommodate  off-road  stresses. 


Bolt  on  armor  required 
upgraded  suspension, 
engine,  and  steering 


Additional  armor  and 
cupola  raise  the  CG 
and  increase  rollovers 


Upgrades: 

•Increased  cab  space 
•Increased  payload 
capacity 

•  Strengthened  frame 


Base  cab  &  flatbed  with 
mission  modules 


Imbalance  in  cupola 
required  motorized  drive 


Upper  deck  space  is 
always  at  a  premium 


Figure  1:  HMMVW  Variants 


The  history  of  the  HMMWV  evolution  has  been  to  increase  the  load.  The  AO  Series  (1984-93) 
had  6.2L  diesel  engine  with  a  3  speed  transmission,  2,500  to  3,632  lb  payload,  7,700  lb  gross 
vehicle  weight.  The  A1  Series  (1991-95)  had  an  improved  driveline  and  suspension,  with  2,500 
to  3,632  lb  payload,  10,000  lb  gross  vehicle  weight.  The  A2  Series  (1994-present)  had  a  6.5  liter 
diesel  engine,  4  speed  electronic  transmission,  with  3,520  to  4,400  lb  payload,  10,300  lb  gross 
vehicle  weight.  The  Expanded  Capacity  Vehicle  (ECV,  1993-present)  has  a  6.5  liter  turbo  diesel 
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engine,  a  suspension  upgrade,  is  capable  of  carrying  the  armor  upgrade  kit,  1,800-5,100  lb 
payload,  with  gross  vehicle  weight  12,100.  The  wheel  rating  is  13,500  lbs. 

Upgrade  kits  for  the  HMMWV  series  include  add-on  armor,  an  armor  suspension  improvement 
kit  to  handle  the  weight  of  the  add-on  armor,  a  winch  kit,  a  central  tire  inflation  kit,  a  water 
fording  kit,  a  gunners  cupola  kit,  and  an  auxiliary  weapon  station  kit.  The  kits  can  be  installed  in 
the  field.  Some  can  be  installed  by  the  crew,  some  require  special  equipment  and  are  installed 
by  the  maintenance  unit. 

A  proposed  ECV2  (not  currently  in  production)  has  an  improved  6.5  liter  turbo  diesel  engine,  a 
new  transmission,  improved  suspension  and  frame  for  an  increased  armor  capability,  1,800- 
4,400  lb  payload  and  GVW  18,000  lbs.  Other  ECV2  enhancements  include  anti-lock  brakes  and 
active  traction  control,  upgraded  suspension,  higher  capacity  drivetrain,  heavier-duty 
tire/Wheel  Assembly  (22.5"  rim,  40"  tire),  stronger  frame  (3  piece  welded),  integral  "A"  armor 
with  attachment  points  for  "B"  armor  kit,  increased  cab  space  (14  cubic  feet),  enhanced  6500 
turbo  diesel  engine,  higher  capacity  transmission,  air  induction  system  and  exhaust  systems. 

Lessons,  insights,  &  observations:  To  achieve  versatility,  vehicles  need  to  be  able  to  have 
reserve  capacity  in  terms  of  volume,  load  bearing,  and  load  mobility  (propulsion,  suspension, 
steering,  braking,  ground  pressure).  HMMWV  evolved  its  versatility  by  increases  to  these.  Note 
also  that  modifications  are  made  at  different  maintenance  levels.  Versatility  should  be 
considered  in  terms  of  the  maintenance  level  at  which  the  changes  can  be  made,  i.e.  unit, 
maintenance  battalion,  depot,  and  production  line.  Note  also  the  use  of  standard 
interchangeable  parts. 

HMMWV  Gunner's  Cupola 

The  gunner's  cupola  includes  the  Gunner's  Shield  Kit  (GSK,  weight  over  115  pounds)  and  the 
Gunner's  Protection  Kit  (GPK,  another  320  pounds),  for  a  total  of  430  pounds.  The  machine 
gun,  its  cradle,  ammunition  box,  and  other  components  add  further  weight.  All  the  elements 
are  shipped  overseas  as  a  kit  where  they  are  assembled  in  theater.  It  mounts  on  the  standard 
HMMWV  roof  hatch. 

The  ring  mount  base  allows  the  gunner  to  rotate  the  cupola  a  full  360  degrees.  The  Center  of 
Gravity  (CG)  of  the  cupola  is  off-center  from  the  axis  of  rotation,  with  the  effect  that  additional 
force  is  needed  to  rotate  the  cupola  "uphill"  when  the  vehicle  is  on  a  slope.  The  force  needed 
to  overcome  the  combined  effects  of  friction  (mass  times  coefficient  of  resistance)  and 
imbalance  (mass  times  the  distance  between  the  CG  and  axis  of  rotation)  is  106  pounds  on  a  30 
percent  slope. 

To  address  this  problem,  engineers  at  the  U.S.  Army  Tank  Automotive  Research,  Development 
and  Engineering  Center  (TARDEC)  designed  the  Battery  Powered  Motorized  Traversing  Unit 
(BPMTU)  to  provide  a  HMMWV  gunner  with  powered  cupola  operations.  The  BPMTU  and  its 
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rear-mounted  power  supply,  positioned  to  help  counterbalance  the  weight  of  the  gun,  mount 
and  shield. 

Lessons,  insights,  &  observations:  The  cupola  had  a  large  imbalance  and  angular  moments. 
Both  are  limiting  physical  characteristics.  The  applicable  requirements  would  need  to  be  leveled 
on  the  rotating  component,  not  the  vehicle  as  a  whole. 

HMMWV  Rollover 

Another  issue  that  surfaced  as  more  and  more  mass  was  mounted  on  the  top  of  the  HMMWV 
was  increased  frequency  of  roll-over  accidents.  HMMWV  roll-overs  are  the  third  leading  cause 
of  death  in  theater  (after  combat  actions  and  IED  explosions).  Roll-over  accidents  increased 
with  the  advent  of  Up-Armored  HMMWVs  and  the  GPK/GSK.  Factors  combining  to  contribute 
to  roll-overs  include  high  CG,  aggressive  driving,  and  obstacle  encounters  (the  HMMWV  was 
designed  to  climb  obstacles,  not  bulldoze  them  out  of  the  way).  Military  safety  teams 
investigated  many  of  these  accidents  and  looked  at  the  need  for  roll-bars  or  other  increased 
protection  for  the  gunner  position,  to  be  factored  into  future  equipment  designs. 

The  additional  armor  and  cupola  raised  the  HMMWV's  CG,  increased  the  risk  of  roll-over. 
Increased  moment  of  inertia  degrades  handling.  On  9  November,  2010,  the  U.S.  Marine  Corps 
issued  a  request  for  information  for  the  HMMWV  roll-over  stability  control  system 
(M6785411I5014).  The  announcement  stated  "Force  protection  requirements  necessitate  the 
addition  of  as  much  as  4800  pounds  of  armor  to  some  HMMWV  variants  which  significantly 
degrades  the  vehicle's  dynamic  performance.  Additional  payload  or  any  off-road  operational 
scenarios  further  diminish  the  vehicle's  stability  resulting  in  un-tripped,  or  maneuver-induced 
roll-over  incidents.  Un-tripped  and  maneuver-induced  roll-over  refers  to  events  where  roll-over 
is  spontaneous  and  not  initiated  by  contact  between  the  tires  and  a  tripping  mechanism  (such 
as  a  curb,  a  soft  shoulder,  a  ditch,  loose  gravel,  a  guard  rail,  etc.).  These  events  are  often 
operator  induced  and/or  exacerbated  by  excessive  speed  and  large  yaw  inputs  to  the  vehicle 
steering." 

Lessons,  insights,  &  observations:  CG  location  and  angular  movements  are  limiting  physical 
characteristics. 


2.4.3  M113 


M113  Development 

The  M113  Armored  Personnel  Carrier  is  in  service  with  more  than  thirty  armies  throughout  the 
world  including  the  United  States  Army.  More  than  50,000  units  have  been  produced  covering 
150  variants  and  versions  during  the  last  20  years.  Initial  design  work  for  the  M113  dates  back 
to  1956  when  the  US  Army  called  for  an  APC  cheaper  and  lighter  than  the  M75  then  under 
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consideration.  In  response  to  these  requirements,  evaluation  studies  were  undertaken  on  T113 
of  aluminum  construction  (3  prototypes)  T117  of  steel  construction  (5  prototypes). 

The  T113  was  marginally  lighter  than  the  T117.  The  difference  in  weight  was  only  one  factor  in 
the  ultimate  choice  of  vehicles  since  to  obtain  an  equal  degree  of  protection,  aluminum  armor 
had  to  be  three  times  as  thick  as  that  of  steel.  However,  rigidity  of  the  aluminum  hull  was  far 
greater  which  enabled  a  number  of  reinforcing  structures  to  be  eliminated,  allowing  more 
useable  interior  space. 

Lessons ,  insights,  &  observations:  Load  bearing  capacity  of  walls  and  structures  are  physical 
characteristic  related  t  versatility. 

Ml  13  Variants 


The  evolution  of  the  M113  Family  of  Vehicles  (FOV)  is  illustrated  in  figure  2. 

A  '"'v  >  ' 


Ml  13  FOV  EVOLUTION 


1960 


Ml  13  (GASOLINE) 


mrr  ICMO  TRACK  )>  Ml(*  (MO*TAA> 

M113A1  (DIESEL) 


1964 


Ml 25  (MORTAR).  MS48  (COO  TRACK). 

M667  (LANCE )  M73C  (CHAP).  M741  (VULCAN) 


1979  Ml  13A2  (COOLING  AND  SUSPENSION) 

M901  (FTV),  M981  (MS TV),  MI015  (KW) 


1987  Ml  13A3  (RISE  UPGRADE) 


J 

Ml 069  (SMOKE),  Ml 064  (MORTAR)  M 1 068  <$ICP$), 
OSV  (BMP-2),  MSB  (SMOKE) 


2000 


ADV  TECH  LIGHT  ARMOR 


SUCH  AS:  XM1 106  (UNIVERSAL  CARRIER),  SEEKER  (INTERIM 
SCOUT  VEHICLE ».  TURRETED  MORTAR  SYSTEM.  H*OH 
MOBILITY  STRETCH  ENGINEERING  SOUAO  VEHICLE 
ARMORED  MEOICAL  EVACUATION  VEHICLE  (AMEC)  / 


Figure  2:  M113  Family  of  Vehicles  Evoluttion 


The  first  major  upgrade  came  in  1964  with  the  introduction  of  the  M113A1  package  which 
replaced  the  original  gasoline  engine  with  a  212  horsepower  diesel  package.  The  new  power 
train  was  soon  incorporated  into  the  existing  vehicle  family  as  the  M113A1,  M577A1,  and 
M106A1,  as  well  as  several  new  derivative  systems.  Some  of  these  new  derivatives  were  based 
on  the  armored  M113  chassis  (the  M125A1  mortar  carrier  and  M741  "Vulcan"  air  defense 
vehicle)  while  others  were  based  on  an  unarmored  version  of  the  chassis  (including  the  M548 
cargo  carrier,  M667  "Lance"  missile  carrier,  and  M730  "Chaparral"  missile  carrier). 


Continuing  modernization  efforts  led  to  the  introduction  of  the  A2  package  of  suspension  and 
cooling  enhancements  in  1979.  As  with  previous  enhancements,  these  upgrades  resulted  in 
further  proliferation  of  the  FOV. 
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Today's  M113  fleet  includes  a  mix  of  these  A2  variants  together  with  other  derivatives 
equipped  with  the  most  recent  A3  RISE  (Reliability  Improvements  for  Selected  Equipment) 
package.  The  standard  RISE  package  includes  an  upgraded  propulsion  system  (turbocharged 
engine  and  new  transmission),  greatly  improved  driver  controls  (new  power  brakes  and 
conventional  steering  controls),  external  fuel  tanks,  and  200  AMP  alternator  with  4  batteries. 
Additional  A3  improvements,  include  incorporation  of  spall  liners  and  provisions  for  mounting 
external  armor. 

A  major  component  of  the  RISE  powertrain  incorporated  into  the  original  M113A3  and  M730A2 
vehicles  is  the  turbocharged  275  hp  6V53T  engine  from  Detroit  Diesel  Corporation.  Replacing 
the  earlier  212  hp  M113A2  engine  with  the  turbocharged  275  hp  model  paved  the  way  for 
improvements  in  performance  as  well  as  survivability  enhancements  such  as  the  incorporation 
of  spall  liners  and  the  possible  addition  of  add-on  armor.  The  improved  performance  and  higher 
chassis  load  capacity  has  also  opened  the  way  for  planners  to  consider  additional  M113  FOV 
derivatives. 

The  new  engine  packages  have  also  been  accompanied  by  improvements  in  the  RISE 
transmission  component.  The  RISE  program  was  introduced  with  the  X200-4  transmission  from 
Allison  Transmission.  The  X-200-4  transmission  replaces  the  three  component  A2  vehicle  drive 
train  (transfer  gear  case,  transmission,  steering  differential).  The  new  transmission,  designed  to 
provide  longer  life  than  the  previous  configuration,  has  proven  durability  that  is  five  times 
greater  than  the  TX-100-1  transmission  that  it  replaced. 

The  Model  X200-4  Transmission  went  into  production  in  1986  for  both  the  M113A3  and 
M730A2  RISE  powered  vehicles.  It  was  designed  for  use  in  vehicles  up  to  32,000  pounds,  a  top 
speed  of  41  mph,  a  maximum  engine  speed  of  2800  RPM,  and  a  power  rating  up  to  275  hp. 

Development  of  the  Model  X200-4A  Transmission  was  prompted  by  the  heavier  derivative 
vehicles  that  will  utilize  the  300  hp  and  350  hp  engines  noted  above.  The  "4A"  model  features 
durability  and  performance  improvements  in  6  separate  areas.  It  is  capable  of  operating  in 
vehicles  up  to  40,000  pounds  with  a  top  speed  of  41  mph.  Most  importantly,  the  new  model 
allows  for  vehicle  power  growth  up  to  350  hp.  Because  of  its  application  from  275-  350  hp,  the 
X200-4A  has  been  phased  into  production  and  is  the  only  transmission  currently  being 
produced  for  the  M113A3  RISE  variants. 

Lessons,  insights,  &  observations:  Engine,  transmission  and  suspension  upgrades  were  needed 
to  accommodate  increased  mass. 

The  M113A3+  mobile  tactical  vehicle  light  (MTVL)  uses  an  M113  hull  that  is  lengthened  34 
inches  and  equipped  with  an  additional  road  wheel  (six  on  each  side).  The  vehicle  was 
developed  as  a  "production-tooled  demonstrator"  with  private-industry  funding  from  United 
Defense. 
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Lessons,  insights,  &  observations:  The  ability  to  modify  the  design  to  increase  volume  (length) 
and  add  a  road  wheel  to  reduce  the  ground  pressure  due  to  increased  mass  are  factors  that 
enhance  versatility.  These  changes  are  made  at  the  production  line,  not  unit,  field  or  depot 
maintenance. 

The  M113A3+  ESV  meets  the  Combat  Engineer  Squad  requirements  to  transport  an  eight  man 
engineer  squad  and  all  of  their  equipment  while  providing  mobility  and  survivability  equal  to 
the  maneuver  force.  The  M113A3+  ESV  supports  the  Engineer  Squad  in  the  performance  of 
both  offensive  and  defensive  obstacle/counter-obstacle  operations  in  support  of  the  maneuver 
force.  The  vehicle  can  be  adapted  to  fulfill  other  engineer  mission  objectives  including:  carrying 
the  Volcano  mine  dispenser,  the  pathfinder  marking  system,  and  towing  the  MICLC  trailer.  The 
basic  configuration  provides: 

•  Ballistic  survivability  equal  to  the  M2A2  IFV 

•  30%  more  volume  under  armor  than  the  M113A3 

•  30%  more  payload  capacity 

•  50%  greater  cross  country  mobility  (equal  to  M1/M2) 

Lessons,  insights,  &  observations:  Payload  capacity  volume  and  weight  are  important  physical 
characteristics  for  versatility. 


2.4.4  Stryker 

There  are  two  basic  versions  (the  Infantry  Combat  Vehicle,  ICV,  and  the  Mobile  Gun  System, 
MGS)  plus  eight  ICV  variants  (and  seven  up-armored  versions  with  "double-Vee"  hull  for 
underbody  blast  protection): 

•  M1128  Mobile  Gun  System  (MGS),  adds  a  turret  with  105  mm  cannon 

•  M1126  Infantry  Carrier  Vehicle  (ICV)  with  remote  Weapon  Station 

•  M1127  Reconnaissance  Vehicle  (RV) 

•  M1129  Mortar  Carrier  Vehicle  (MC) 

•  M1130  Command  Vehicle  (CV) 

•  M1131  Fire  Support  Vehicle  (FSV) 

•  M1132  Engineer  Squad  Vehicle  (ESV) 

•  M1133  Medical  Evacuation  Vehicle  (MEV) 

•  M1134  Anti-Tank  Guided  Missile  Vehicle  (ATGM) 

•  M1135  Nuclear,  Biological  &  Chemical  Reconnaissance  Vehicle  (NBC  RV) 

The  Stryker  was  based  derived  from  the  Interim  Armored  Gun  System,  which  was  based  on  the 
Canadian  LAV  III,  which  was  based  on  the  Swiss  MOWAG  Piranha  vehicle.  When  then  turret 
and  cannon  were  added  for  the  MGS,  the  body  was  not  strong  enough  to  support  the  load  and 
had  to  be  redesigned.  The  ICV  version  of  the  Stryker  could  be  configured  for  different  mission 
variants  because  of  the  large  volume  in  the  passenger  compartment  and  large  upper  deck  area. 
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Slat  side  armor  for  RPG  protection  conflicts  with  external  side  storage.  Figure  3  shows  several 
configurations,  including  operational  employment  with  the  upper  deck  area  consumed  for 
stowage. 


Figure  3:  Syker  Configurations 


To  meet  urgent  operational  needs,  Styker  was  tested,  produced,  fielded  and  fought  in  combat 
all  in  parallel.  The  operational  tempo  was  much  higher  than  planned  for,  the  mix  of  on-  and  off¬ 
road  user  were  in  inverse  ratio  from  the  development  operational  mode  expectations.  The 
threat  and  operational  environment  were  also  much  different  from  developmental 
expectations. 

Lessons/insights/observations:  Reserve  load-bearing  strength  of  the  structure  is  needed  for 
versatility ,  as  are  large  "unused"  volume,  and  reserve  deck  &  exterior  surface  area. 


2.4.5  PlNZGAUER 

The  Swiss  Pinzgauer  platform  is  the  basis  for  a  variety  of  military  and  civilian  utility  vehicles  in 
service  with  armed  forces  in  29  countries  with  at  least  8  variants.  The  base  vehicle  (cab, 
powertrain,  flatbed  body)  is  produced  in  4x4  and  6x6  configurations,  and  can  be  integrated  with 
different  shelter  bodies  and  special  equipment.  It  can  be  outfitted  with  standard  wheel-tire 
running  gear  or  tracked  bogey  wheels  for  greater  mobility  (see  figure  4). 
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Figure  4:  Pinzgauer  Configurations 


The  first-generation  Pinzgauer  vehicle  was  manufactured  in  710  4x4  and  712  6x6.  BAE  Systems 
introduced  the  Pinzgauer  II,  in  716  4x4  and  718  6x6  configurations.  The  new  vehicle  features  an 
upgraded  engine,  enhanced  suspension  and  flexible  amour  solutions.  The  height  and  width  of 
the  vehicle  were  increased  for  extra  internal  space. 

Lessons/insights/observations:  Large  volume  is  needed  for  versatility.  A  design  that  can  be 
stretched  (4x4  and  6x6)  enhanced  versatility.  Ability  to  swap  wheels  for  bogey  wheels  to  reduce 
ground  pressure  enhances  ability  to  accommodate  increased  mass.  Modular  design  of  base 
vehicle  with  container  or  shelter  is  an  approach  to  platform  versatility. 


2.4.6  Yak 


The  Rheinmetall  Yak  is  an  armored  and  mine-protected  multi-purpose  transport  vehicle,  based 
on  the  Swiss  MOWAG  Duro  IMP  chassis.  The  Yak  is  based  on  two  fixed  components:  (1)  chassis 
with  the  cab,  and  (2)  interchangeable  modular  shelter  (see  figure  5).  It  can  be  quickly  modified 
to  suit  wide  variety  of  missions. 


Figure  5:  Yak  Flatbed  and  Flatbed  with  Shelter  Module 

Lessons/insights/observations:  Large  volume  is  needed  for  versatility.  Modular  design  of  base 
vehicle  with  container  or  shelter  is  an  approach  to  platform  versatility. 
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2.4.7  Boxer 


The  Boxer  design  is  based  on  a  modular  structure  selected  to  give  the  maximum  flexibility  for 
multi-purpose  operation.  Mission  modules  fit  into  the  base  vehicle.  The  base  vehicle  operates 
independently  from  the  modules.  The  modules  are  interchangeable  in  less  than  one  hour.  The 
vehicle  incorporates  a  high  level  of  standardization  and  uses  commercially  proven  automotive 
components.  The  8x8  vehicle  provides  a  load  capacity  to  8t  and  has  an  internal  capacity  of  more 
than  14m3. 

Add-on  modular  armor  which  provides  protection  against  top  attack  bomblets,  anti-tank  and 
antipersonnel  mines,  360°  heavy  machine  gun  fire  and  artillery  fragments.  Modular  armor  is 
sandwiched  between  the  vehicle  cell  and  the  steel  coat  and  all  three  elements  are  secured  by 
fastening  bolts. 

Boxer  has  an  integrated  weapon  station  on  which  various  weapons  can  be  mounted,  including 
7.62mm  or  12.7mm  machine  guns  and  40mm  grenade  launcher. 

Lessons/insights/observations:  Modifications  that  can  be  made  at  the  unit  or  field  maintenance 
level  contribute  to  versatility.  Modular  design  of  base  vehicle  with  container  or  shelter,  large 
free  volume  in  shelter,  and  use  of  standard,  interchangeable  parts  also  contribute  to  versatility. 


2.5  Findings  and  Recommendations 

The  physical  characteristics  of  reserve  capacity  consist  of  mass  properties,  structural  properties 
and  computer/electronics  properties  (see  figure  6).  Critical  mass  properties  are  mass,  CG 
location,  angular  moments,  and  imbalances.  Critical  structural  properties  are  volume,  internal 
and  external  surface  mounting  area,  load  bearing  strength.  Critical  computer/electronics 
properties  are  bandwidth,  throughput,  I/O  ports,  card  slots,  and  electrical  power. 
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Figure  6:  Physical  Characteristics  for  Reserve  Capacity  Enabling  Versatility 


The  physical  characteristics  of  reserve  capacity  apply  to  the  vehicle  as  a  whole,  and  its  physical 
decomposition  separated  or  separable  parts  (see  the  illustration  in  figure  7): 

•  Subsystems  or  components  that  can  be  moved  to  different  fixed  positions  or 
continuously  (e.g.,  chassis,  turret,  cupola,  sensor  pod,  etc.) 

•  Groups  of  subsystems  or  components  that  can  be  moved  independently  but  are 
physically  connected  (e.g.  entire  vehicle,  chassis+turret,  turret+cupola,  etc.) 

•  Sequestered  compartments  (e.g.,  crew  compartments,  passenger/cargo  compartments, 
engine  compartment) 

•  Line  Replaceable  Units  (LRUs),  Line  Replaceable  Modules  (LRMs),  computer  and 
electronics  components 
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Figure  7:  Illustration  of  Vehicle  Physical  Architecture  Decomposition 


The  following  examples  illustrate  requirements  for  reserve  capacity: 

•  The  system  shall  be  meet  all  performance  requirements  with  a  change  in  vehicle  CG 
location  of  5%  of  vehicle  dimension  (i.e.,  longitudinal  change  5%  of  length,  lateral 
change  up  to  5%  of  width,  elevation  change  up  to  5%  of  height) 

•  The  system  shall  be  meet  all  performance  requirements  with  a  change  in  turret  mass  of 
10% 

•  The  turret  shall  have  20%  upper  deck  surface  area  reserve  capacity 

•  The  chassis  frame  shall  have  50%  reserve  load  bearing  capacity 

•  The  computer/electronics  hardware  with  backplane  architecture  shall  have  10%  reserve 
capacity  for  card  slots 

•  The  data  buses  shall  have  50%  reserve  bandwidth 

•  The  system  and  subsystems  shall  have  10%  reserve  capacity  in  memory,  processing 
throughput,  data  bus  bandwidth,  expansion  slots,  and  power  supply  in 
computer/electronics  subsystems  and  components. 

•  The  XYZ  compartment  shall  have  reserve  volume  able  to  add  1  component  of  size 
H1W1L1  or  2  components  of  size  H2W2L2  or  3  component  of  H3W3L3 

The  following  four  statements  are  the  general  form  of  the  parametric  requirements  for  physical 
characteristics  enabling  versatility: 
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•  Subsystems  shall  be  designed  with  compatible  reserve  capacities  to  enable  the  vehicle 
system  to  perform  all  functions  effectively  and  meet  system  performance  requirements 
with  X%  change  in  <mass  property>  of  decomposition  element> 

•  The  decomposition  component  shall  have  X%  structure  property>  reserve  capacity 

•  The  decomposition  component  shall  have  X  amount  of  structure  property>  reserve 
capacity 

•  The  <  computer/electronics  component  >  shall  have  X%  reserve  capacity  for  <computer 
and  electronics  property> 

The  requirements  statements  are  independent  of  the  vehicle  functions  and  functional 
architecture.  The  requirements  for  reserve  capacity  in  physical  characteristics  are  not 
independent  of  the  physical  decomposition.  The  amount  of  reserve  capacity ;  by  physical 
decomposition  and  physical  characteristic  are  to  be  determined  by  the  program  systems 
engineers  to  meet  operational  requirements. 
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3  Case  Study  2:  Example  Application  of  RDECOM  Project  Plan  Template  over 


the  Course  of  a  Science  and  Technology  Project 


In  August  2010,  TARDEC's  parent  agency  RDECOM,  issued  new  OPORD  10-065  "RDECOM 
Systems  Engineering  Policy"  establishing  an  Organizational  Standard  Process  (OSP)  for  rigorous 
Systems  Engineering  and  Project  Management  to  Science  and  Technology  (S&T)  projects, 
following  the  intent  of  the  Weapon  Systems  Acquisition  Reform  Act  (WSARA)  of  2009. 

Appendix  B  to  OPORD  10-065  contains  a  template  and  guidance  to  prepare  and  maintain  the 
Project  Plan  to  document  Project  Management  (PM),  SE  and  SE  Management  (SEM) 
organizations,  procedures  and  status.  OPORD  10-065  requires  that  the  Project  Plan  be  used  on 
all  Army  Technology  Objective-Demonstration  (ATO-D)  projects  beginning  in  or  after  1QFY11 
(ATO-D  projects  are  now  called  Technology  Enabled  Capability  Demonstration  -TECD  - 
projects).  The  Project  Plan  is  conceived  as  a  living  document  to  be  maintained  and  updated 
over  the  course  of  the  project  to  help  assure  quality  and  completeness  of  PM,  SEM  and  SE 
activities. 

The  template  and  guidance  for  the  Project  Plan,  Appendix  B  to  OPORD  10-065,  is  contained  in 
the  accompanying  file  "Annex  B  to  OPORD  10-065,  SE  Policy,  RDECOM  Project  Plan 
Template.pdf".  The  guidance  and  template  are  generic,  intended  to  be  tailored  and  applied  by 
all  of  RDECOM's  subordinate  command.  TARDEC  began  an  effort  to  develop  more  specific 
policy,  procedures,  guidance,  forms  and  templates  to  comply  with  OPORD  10-065.  TARDEC 
identified  the  need  to  produce  an  example  of  a  completed  project  plan,  and  associated 
technical  annexes,  to  provide  a  concrete  example  for  training  PM,  SEM  and  SE  personnel,  an  as 
an  example  to  follow.  The  specific  example  is  complements  the  descriptions  of  procedures  and 
formats. 

TARDEC  policies,  guidance,  forms  and  templates  for  the  Project  Plan  continued  to  develop  and 
evolve  in  parallel  with  our  activity  to  generate  a  specific  example  and  it  history  of  evolution. 

We  held  bi-weekly  detailed  technical  reviews  with  TARDEC  to  help  ensure  that  our  example 
remained  consistent  with  TARDEC's  parallel  development  and  refinement  of  policies  and 
guidance.  Our  activity  to  apply  TARDEC's  policies  and  procedures  provided  feedback  to  TARDEC 
that  in  some  cases  resulted  in  refinement  of  the  policies  and  procedures. 

We  created  the  example  illustration  of  the  Project  Plan  and  its  evolution  for  a  current  TARDEC 
S&T  project  that  was  nearing  completion.  The  S&T  project  was  the  "MTRS  Communications 
and  Situation  Awareness  Mast"  (MCSAM)  project.  MTRS  stands  for  "Man  Transportable  Robot 
System."  MTRS  is  a  TACOM  Program  of  Record  (PoR).  If  successful,  the  MCSAM  S&T  project 
will  produce  a  payload  for  the  MTRS  that  will  transition  to  the  PoR  at  the  end  of  the  S&T 
project.  The  MCSAM  project  preceded  OPORD  10-065.  The  Project  Plan  and  associated 
technical  annexes  were  not  developed  by  the  S&T  project.  We  developed  them  in  retrospect, 
as  though  they  had  been  prepared  during  the  course  of  the  MCSAM  project.  We  chose  the 
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MCSM  project,  in  consultation  with  TARDEC,  because  we  had  advised  on  the  project  and  were 
familiar  with  the  details  and  history  of  the  project. 

The  Project  Plan  is  conceived  as  a  living  document  to  be  maintained  and  updated  over  the 
course  of  the  project  to  help  assure  quality  and  completeness  of  PM,  SEM  and  SE  activities.  To 
show  how  the  project  plan  evolves  over  the  course  of  a  project,  we  generated  snapshots  of  the 
Project  Plan  and  associated  technical  annexes  at  six  points  in  time  over  the  course  of  the 
project  corresponding  to  the  six  required  technical  reviews: 

1.  Stakeholder  Needs  Review  (SNR) 

2.  System  Requirements  Review  (SRR) 

3.  System  Functional  Review  (SFR) 

4.  Preliminary  Design  Review  (PDR) 

5.  Critical  Design  Review  (CDR) 

6.  Test  Readiness  Review  (TRR) 

In  addition  to  the  main  body  of  the  Project  Plan,  we  prepared  examples  of  nine  associated 
technical  annexes: 

Annex  A:  Readiness  Levels  and  Assessment  Criteria 

Annex  B:  Technology  Transition  Plan 

Annex  C:  Supplemental  Checklists 

Annex  D:  Technical  Review  Guidelines 

Annex  E:  Technical  Review  Checklists 

Annex  F:  Requirements  Management  Plan 

Annex  G:  Configuration  Management 

Annex  H:  Risk  Management  Plan 

Annex  I:  Backup  Material 

The  information  contents  of  the  Project  Plan  main  body  and  associated  technical  annexes  are 
described  in  the  remainder  of  this  section.  Files  containing  the  six  instances  of  the  Project  Plan 
and  associated  technical  annexes  are  contained  in  the  accompanying  files,  and  referenced  in 
the  descriptions. 


3.1  Project  Plan  Main  Body 


The  six  snapshots  of  the  Project  Plan  main  body  for  the  MCSAM  project  are  contained  in  the 
following  files: 

PP  Main  MCSAM  SNR  PP.docx 
PP  Main  MCSAM  SRR  PP.docx 
PP  Main  MCSAM  SFR  PP.docx 
PP  Main  MCSAM  PDR  PP.docx 
PP  Main  MCSAM  CDR  PP.docx 
PP  Main  MCSAM  TRR  PP.docx 
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The  template  and  guidance  for  the  Project  Plan,  Appendix  B  to  OPORD  10-065,  is  contained  in 
the  accompanying  file  "Annex  B  to  OPORD  10-065,  SE  Policy,  RDECOM  Project  Plan 
Template.pdf".  The  outline  of  the  Project  Plan  is: 


1  Purpose  of  Project  Plan 

2  Project  Purpose  &  Scenario 

3  Project  Background 

4  Project  Scope  Statement 

5  Guidance  Documents 

6  Project  Technical  Status  as  of  Date  of  Project  Plan 

7  Stakeholders  and  Responsibilities 

8  Stakeholder  Communication/Coordination 

8.1  Stakeholder  Coordination  Plan 

8.2  Conflict  Management 

8.3  Organization  Chart 

8.4  Meetings  and  Status  Reporting 

8.5  Technical  Reviews 

9  System  Capabilities,  Requirement,  and  Design  Considerations 

10  Acquisition  Strategy 

11  Life  Cycle  Model 

12  Resources  and  Schedule 

12.1  WBS  Activities 

12.2  Schedule 

12.3  Basis  of  Estimate  /  Work  Product  Size  Estimates 

12.4  Effort,  Staffing,  and  Cost  Estimate 

12.5  Engineering  Environment 

12.6  Contractor  Efforts 

13  Project  Training  Needs 

14  New  Technology  Pilots  and  Process  Pilots 

15  System  Engineering  Process 

15.1  Stakeholder  Requirements  Definition 

15.2  Requirements  Analysis 

15.3  Architectural  Design 

15.4  Implementation 

15.5  Integration 

16  Product  Evaluation 

16.1  Peer  Reviews 

16.2  Verification 

16.3  Validation 

17  Transition 

18  Requirements  Management 

19  Interface  Management 
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20  Process  Assurance  Plan 

21  Configuration  Management 

22  Data  Management 

23  Project  Deliverables/Work  Products 

24  Simulation  Support  Planning 

25  Risk  Management  Plan 

25.1  Risk  Management  Process 

25.2  Risk  Identification  &  Profile 

26  Measurement  and  Analysis 

26.1  Technical  Objectives 

26.2  Technical  Analyses 

27  Causal  Analysis  and  Resolution 

28  Decision  Analysis  and  Resolution 

29  Corrective  Action  Tracking 

30  Security 

31  Data  Rights 

32  List  of  Acronyms 


3.2  Annex  A:  Readiness  Levels  and  Assessment  Criteria 

This  annex  contains  the  definitions,  descriptions,  and  verification  questions  for  technical, 
integration,  and  manufacturing  readiness  levels  (TRL,  IRL  and  MRL).  S&T  projects  are  intended 
to  advance  the  readiness  levels  of  the  subject  technologies,  to  the  point  where  the  technology 
is  ready  for  transition  to  a  PoR.  The  MCSAM  project  had  specific  requirements  to  achieve  TRL- 
7,  IRL-7  and  MRL-7  by  the  end  of  the  project. 

Annex  A  was  prepared  one  time  for  the  SNR.  It  was  not  changed  or  updated  in  subsequent 
reviews.  Annex  A  is  contained  in  the  file  "PP  Annex  A  Readiness  Levels. docx."  The  definitions, 
descriptions,  and  verification  questions  for  the  readiness  levels  were  provided  by  TARDEC. 


3.3  Annex  B:  Technology  Transition  Agreement 

The  Technology  Transition  Agreement  is  the  agreement  between  the  development  agent  and 
the  acquisition  agent  for  the  target  PoR.  In  the  MCSAM  project,  the  development  agent  was 
TARDEC  and  the  acquisition  agent  was  TACOM  RS-JPO.  The  MCSAM  project  had  a  well-defined 
transition  program  and  partner.  TARDEC  engaged  in  the  MCSAM  project  at  the  request  of  RS- 
JPO.  In  this  respect,  the  MCSAM  project  is  somewhat  atypical  for  S&T  projects,  and  its 
Technology  Transition  Agreement  is  more  specific  and  detailed  than  others  might  be. 
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The  Technology  Transition  Agreement  was  developed  initially  for  the  SNR,  then  updated  once 
at  SRR.  The  two  snapshots  of  the  Technology  Transition  Agreement  for  the  MCSAM  project  are 
contained  in  the  files: 

PP  Annex  B  MCSAM  Technology  Transition  Agreement  SNR.docx 
PP  Annex  B  MCSAM  Technology  Transition  Agreement  SRR.docx 

The  contents  of  the  Technology  Transition  Agreement  are: 

1.  Introduction 

1.1  Purpose/Scope 

1.2  Summary 

2.  Basic  Transition  Agreement 

2.1  Technology  Name 

2.2  Technology  Description 

2.3  Target  Acquisition  Program 

2.4  Acquisition  Program  Technology  Need 

2.5  Integration  Strategy 

2.6  Program  Manager/Project  Officer 

2.7  Technology  Manager 

2.8  Capability  Requirement  Basis 

2.9  Resource  Sponsor/Requirements  Officer 

3.  Technical  Details  And  Programmatics 

3.1.  Current  Status  of  Technology 

3.2.  Technology  Development  Strategy 

3.3.  Transition  Readiness 

3.4.  Program  Plan 

4.  References 

Appendix  A:  Operational  Requirements  Document  (ORD) 

1.  General  Description  of  Operational  Capability 

a.  Overall  Mission  Area 

b.  Type  of  System  Proposed 

c.  Operational  Concept 

d.  Support  Concept 

e.  Mission  Need  Statement  Summary  (MNS) 

2.  Threat 

3.  Shortcomings  of  Existing  Systems 

4.  Capabilities  Required 

a.  System  Performance 

b.  Logistics  and  Readiness 

c.  Critical  System  Characteristics 

5.  Integrated  Logistics  Support 

a.  Maintenance  Planning 

b.  Support  Equipment 
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c.  Human  Systems  Integration 

d.  Computer  Resources 

e.  Other  Logistics  Considerations 

6.  Infrastructure  Support  and  Interoperability 

7.  Force  Structure 

8.  Schedule  Considerations 


3.4  Annex  C:  Supplemental  Checklists 

The  Supplemental  Checklists  are  spreadsheets  forms.  They  are  the  means  for  documenting  and 
tracing  relationships  among  stakeholder  needs,  system  requirements,  system  functions, 
configuration  items  and  subsystems,  and  testing  requirements.  The  checklist  format  was 
provided  by  TARDEC,  and  instantiated  for  the  MCSAM  project  by  WSU. 

The  Supplemental  Checklists  are  updated  at  each  technical  review  with  (1)  and  new  worksheet 
for  the  current  review,  and  (2)  updates  to  the  sections  filled  in  at  the  previous  reviews.  The 
updates  illustrate  the  addition  and  refinement  of  needs,  requirements  and  functions. 

The  Supplemental  Checklists  for  the  MCSAM  project  are  contained  in  the  following  files: 

PP  Annex  C  MCSAM  Supplemental  Checklists  SNR.xls 
PP  Annex  C  MCSAM  Supplemental  Checklists  SRR.xls 
PP  Annex  C  MCSAM  Supplemental  Checklists  SFR.xls 
PP  Annex  C  MCSAM  Supplemental  Checklists  PDR.xls 
PP  Annex  C  MCSAM  Supplemental  Checklists  CDR.xls 
PP  Annex  C  MCSAM  Supplemental  Checklists  TRR.xls 

The  Supplemental  Checklists  consist  of  the  following  five  worksheets  (one  worksheet  serves 
both  PDR  and  CDR): 

Project  Needs  Checklist  (SNR) 

Project  Requirements  Checklist  (SRR) 

Functional  Baseline  Checklist  (SFR) 

Allocated/Product  Baseline  Checklist  (PDR  &  CDR) 

Test  Readiness  Review  Checklist  (TRR) 

Project  Needs  Checklist  (SNR).  At  SNR,  each  project  need  is  documented  on  a  row  with  the 
following  information  fields: 

Unique  ID  Number 
Rank  Order 
Project  Need 
Rationale 
Type 

Source  Document 
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Link  to  Other  Need  Numbers 
Agreed  to  by  All  Parties  Check 
Date  Added  or  Changed 

Project  Requirements  Checklist  (SRR).  At  SRR,  each  project  requirement  is  documented  on  a 
row  with  the  following  information  fields: 

Unique  Requirement  Number 
Priority 

Project  Requirement 
Type 

Derived  from  Need  Type 

Rationale 

Source  Document 

Validation  Method/Test 

Linked  to  Needs  Numbers 

Linked  to  Other  Requirement  Numbers 

Singularized  Check 

Achievable  Check 

Affordable  Check 

Verifiable  Check 

Unambigious  Check 

Stated  as  a  Shall  Check 

Agreed  to  by  All  Parties  Check 

Functional  Baseline  Checklist  (SFR).  At  SFR,  each  function  is  documented  on  a  row  with  the 
following  information  fields: 

Unique  Number 
Level 

System  Level  Requirements  Linked 

Function 

Definition 

Rationale 

Derived  Functional  Requirements 

Preconditions  for  Testing 

Additional  Interface  Requirements 

Notes  &  Outstanding  Issues 

Singularized  Check 

Achievable  Check 

Affordable  Check 

Verifiable  Check 

Unambigious  Check 

Stated  as  a  Shall  Check 

Agreed  to  by  All  Parties  Check 


Contract  Number:  H98230-08-D-01 71  D02,  TT02,  RT0026 

Report  No.  SERC-2012-TR-015-5 
August  31, 2012 

UNCLASSIFIED 

37 


All  Columns  Filled  Check 


Allocated/Product  Baseline  Checklist  (PDR  &  CDR).  At  PDR,  each  configuration  item  is 
documented  on  a  row  with  the  following  information  fields: 

Unique  Number 
Level 

System  Level  Requirements  Linked 

Configuration  Item  Name  with  Subsystem  Product  Specifications 

Definition 

Rationale 

Validation  Method/Test 

Linked  Interface  Control  Documents  (ICDs) 

Notes  &  Outstanding  Issues 
Singularized  Check 
Achievable  Check 
Affordable  Check 
Verifiable  Check 
Unambigious  Check 
Stated  as  a  Shall  Check 
Agreed  to  by  All  Parties  Check 
All  Columns  Filled  Check. 

At  CDR,  the  following  additional  fields  are  added: 

ICDs  Completed  Check 

Build  Drawings  Completed  Check 

75-90%  Manufacturing  Quality  Check 

Specifications  Achievable  with  the  Current  Design  Check. 

Test  Readiness  Review  Checklist  (TRR).  At  TRR,  each  test  is  documented  on  a  row  with  the 
following  information  fields: 

Unique  Test  Number 
Requirement  Description 
System  Configuration  Item  or  Subsystem 
Test  Procedure 

Testing  Preconditions  or  Equipment  Needed,  Duration  of  Scheduled  Test  and  Date 
Number  of  Test  Articles 
Safety  Risks 
Test  Site 

Site  Properly  Resourced  Check 

Site  Properly  Staffed  Check 

Site  Booked  and  Available  and  Booked  Check 

Passing  Test  Risk,  Expected  Results 

Pass  /  Fail  Criteria 
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Notes  &  Outstanding  Requirements 
All  Columns  Filled  Check 


After  the  tests  are  completed,  two  additional  fields  are  added:  Test  Passed  or  Failed,  Actual 
Testing  Results. 


3.5  Annex  D:  Technical  Review  Guidelines 

The  Technical  Review  Guidelines  were  documented  once  at  the  SNR,  and  were  not  updated  for 
the  subsequent  technical  reviews.  The  Technical  Review  Guidelines  are  contained  in  the  file 
"PP  Annex  D  Technical  Review  Guidelines. docx",  and  were  provided  by  TARDEC.  The  guidelines 
contain  a  section  for  each  of  the  six  required  technical  reviews,  the  following  contents: 

SNR 

Purpose  of  review 
Problem  identification 
Stakeholder  identification 
Documenting  stakeholder  needs 
Stakeholder  needs  management 
Entrance  criteria  checklist 
Conducting  the  review 
Review  exit  criteria 
Definitions  of  terms 

SRR 

Purpose  of  review 
Requirements  analysis 
Documenting  requirements 
Requirements  management 
Entrance  criteria  checklist 
Conducting  the  review 
Review  exit  criteria 
Definitions  of  terms 

SFR 

Purpose  of  review 
Functional  decomposition 

Linking  system  requirements  to  applicable  functions 
Developing  lower  level  functional  requirements 
Documenting  lower  level  functional  requirements 
Lower  level  requirements  management 
Developing  other  supporting  documentation 
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Entrance  criteria  checklist 
Conducting  the  review 
Review  exit  criteria 
Definitions  of  terms 

PDR 

Purpose  of  review 

Completing  the  Work  Breakdown  Structure  &  identifying  configuration  items 

Linking  functions  to  subsystem  configuration  items 

Developing  internal  and  external  interface  control  documents 

Documenting  lower  level  functional  requirements 

Creating  subsystem  product  specifications 

Subsystem  product  specification  management 

Technology  maturity  assessment  &  creating  preliminary  engineering  drawings 

Developing  other  supporting  documentation 

Conducting  the  review 

Review  exit  criteria 

Definitions  of  terms 

CDR 

Purpose  of  review 

Completing  product  baseline  information  started  at  PDR 
Completing  the  detailed  design 

System  and  subsystem  product  specification  management 

Completing  the  validation  and  test  plan 

Developing  other  supporting  documentation 

Conducting  the  review 

Review  exit  criteria 

Definitions  of  terms 

TRR 

Purpose  of  review 

Completing  test  and  evaluation  specifications 

Verifying  system  requirements  are  linked  to  testing  specifications 

Completing  the  Test  and  Evaluation  Master  Plan 

Verifying  testing  resources  identified,  agreed  to  procedures  and  available 

Failure  reporting,  processing  for  corrective  action  and/or  deviation  authorization 

Other  supporting  documentation 

Conducting  the  review 

Review  exit  criteria 

Definitions  of  terms 
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3.6  AnnexE:  Technical  Review  Checklists 


The  technical  review  checklists  document  the  status  assessment,  status  description,  expected 
completion  date,  and  documentation  references  for  entrance  criteria,  conduct  of  the  review, 
and  exit  criteria  for  each  of  the  six  required  technical  reviews.  The  technical  review  checklists 
are  the  means  for  documenting  and  tracking  execution  of  the  technical  reviews.  The  Technical 
Review  Checklists  are  worksheets,  with  one  sheet  for  each  technical  review.  The  MCSAM 
Technical  Review  Checklists  are  contained  in  the  following  files: 

PP  Annex  E  MCSAM  Technical  Review  Checklists  SNR.xls 
PP  Annex  E  MCSAM  Technical  Review  Checklists  SRR.xls 
PP  Annex  E  MCSAM  Technical  Review  Checklists  SFR.xls 
PP  Annex  E  MCSAM  Technical  Review  Checklists  PDR.xls 
PP  Annex  E  MCSAM  Technical  Review  Checklists  CDR.xls 
PP  Annex  E  MCSAM  Technical  Review  Checklists  TRR.xls 
The  formats  of  the  technical  review  checklists  were  provided  by  TARDEC,  and  instantiated  for 
the  MCSAM  project  by  WSU. 


3.7  Annex  F:  Requirements  Management  Plan 

The  Requirements  Management  Plan  was  prepared  one  time  at  SNR,  and  was  not  updated.  The 
Requirements  Management  Plan  annex  is  referenced  in  the  Project  Plan  main  body,  section  18, 
Requirements  Management.  The  Requirements  Management  Plan  annex  F  is  contained  in  the 
file  "PP  Annex  F  MCSAM  Req  Mgmnt  Plan.docx".  The  basic  plan  was  provided  by  TARDEC  and 
modified  for  the  MCSAM  project  by  WSU.  The  Requirements  Management  Plan  annex  contains 
the  following  content: 

1.0  Introduction 

1.1  Background 

1.2  Mission 

1.3  Project  Organization  Description 
2.0  Process 

2.1  Process  Flow 
3.0  Procedures 

3.1  Overview 

3.2  Requirements  Management  Process 

3.2.1  Create/Update  Change  Proposal 

3.2.2  Compile  Change  Proposals 

3.2.3  Requirements  Change  Control  Review 

3.2.4  Update  Requirements  Baseline  And  Release  New  Requirements  Baseline 

3.2.5  Update  Project's  Doors  Module(s) 

4.0  Metrics 
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4.1  Quarterly  And  Cumulative  Tracking  Of  Proposals 

4.2  Percentage  Of  Proposals  Approved 


3.8  Annex  G:  Configuration  Management 

The  Configuration  Management  Plan  was  prepared  one  time  at  SRR,  and  was  not  updated.  The 
Configuration  Management  Plan  annex  is  referenced  in  the  Project  Plan  main  body,  section  21, 
Configuration  Management.  The  Configuration  Management  Plan  annex  G  is  contained  in  the 
file  "PP  Annex  G  MCSAM  Config  Mgmnt  Plan.docx".  The  basic  plan  was  provided  by  TARDEC 
and  modified  for  the  MCSAM  project  by  WSU.  The  Configuration  Management  Plan  annex 
contains  the  following  content: 

1.0  Introduction 

1.1  Scope 

1.2  Project  Organization  Description 
2.0  Reference  Documents 

3.0  Concept  of  Operations  and  Acquisition  Strategy 

3.1  Configuration  Management  Concept  of  Operations 

3.1.1  Configuration  Management  Objectives 

3.2  Configuration  Management  Acquisition  Strategy 

3.2.1  Baselines 
4.0  Organization 

4.1  Core  Team 

4.2  Supporting  IPTs,  Sub-IPTs,  and  APMs 

4.3  Change  Control  Board 

4.4  Roles  and  Responsibilities 
5.0  Data  Management 

5.1  Configuration  Item  Naming  Convention 

5.2  Format  and  Storage 

6.0  Configuration  Management  Process 

6.1  Configuration  Item  Identification 

6.2  Configuration  Item  Change  Process 

6.2.1  Configuration  Manager  Process  Responsibilities 

6.2.3  Metrics 

6.2.4  Audits 

6.2.5  Future  Configuration  Management  Planning 
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3.9  Annex  H:  Risk  Management  Plan 


The  Risk  Management  Plan  was  prepared  one  time  at  SRR,  and  was  not  updated.  The  Risk 
Management  Plan  annex  is  referenced  in  the  Project  Plan  main  body,  section  25,  Risk 
Management.  The  Risk  Management  Plan  annex  H  is  contained  in  the  file  "PP  Annex  H  MCSAM 
Risk  Mgmnt  Plan.docx".  The  basic  plan  was  provided  by  TARDEC  and  modified  for  the  MCSAM 
project  by  WSU.  The  Risk  Management  Plan  annex  contains  the  following  content: 

1.0  Approach 

1.1  Introduction  And  Overview 

2.0  Organization,  Roles,  And  Responsibilities 

2.1  Chief  Systems  Engineer 

2.2  Project  Lead 

2.3  Project  Systems  Engineering  Lead 

2.4  Risk  Review  Board 

2.5  Risk  Manager 

2.6  Risk  Recon  Tool  Administrator 
3.0  Risk  Management  Reviews 

3.1  Risk  Ipt  Meetings 

4.0  Risk  Management  Process 

4.1  Risk  Identification 

4.2  Risk  Analysis  And  Ranking 

4.3  Risk  Mitigation  Planning 

4.4  Risk  Monitoring 

4.5  Integration  With  Other  Program  Management  Processes 
5.0  Risk  Management  Training 


3.10  Annex  I:  Backup  Material 

The  Backup  Material  annex  contains  additional  project  data  supporting  and  referenced  in  the 
Technical  Review  Checklists.  The  Backup  Material  annexes  are  contained  in  the  following  files: 
PP  Annex  I  MCSAM  Backup  Material  SNR.docx 
PP  Annex  I  MCSAM  Backup  Material  SRR.docx 
PP  Annex  I  MCSAM  Backup  Material  SFR.docx 
PP  Annex  I  MCSAM  Backup  Material  PDR.docx 
PP  Annex  I  MCSAM  Backup  Material  CDR.docx 
PP  Annex  I  MCSAM  Backup  Material  TRR.docx 

The  Backup  Material  document  contains  a  section  for  each  of  the  six  required  reviews  (SNR, 
SRR,  SFR,  PDR,  CDR,  TRR)  with  the  following  subsections: 

1  Major  Developments 
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2  Major  Issues 

3  Major  Risks,  Conditions,  Consequences  And  Mitigations 

4  Major  Project  Artifacts  List 

5  Major  Objectives  Prior  To  The  Next  Technical  Review 

6  Major  Lessons  Learned 

7  Major  Corrective  Actions 
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D02,  TT02,  RT0026 


Appendices 


1.  Project  Plan  Template 

2.  MTRS  Communications  and  Situation  Awareness  Mast  (MCSAM)  Project  Plan  V6.1 

3.  MTRS  Communications  and  Situation  Awareness  Mast  (MCSAM)  Project  Plan  Backup 
Materials 

4.  Project  Plan  Annex  A  Readiness  Levels 

5.  Project  Plan  Annex  B  MCSAM  Technology  Transition  Agreement 

6.  Project  Plan  Annex  C  MCSAM  Supplemental  Checklists 

7.  Project  Plan  Annex  D  Technical  Review  guidelines 

8.  Project  Plan  Annex  E  MCSAM  Technical  Review  Checklists 

9.  Project  Plan  Annex  F  MCSAM  Requirement  Management  Plan 

10.  Project  Plan  Annex  G  MCSAM  Configuration  Management  Plan 

11.  Project  Plan  Annex  H  MCSAM  Risk  Management  Plan 
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